Wagering game with encryption and authentication

ABSTRACT

A computerized wagering game system includes a gaming module comprising gaming code which is operable when executed on to conduct a wagering game on which monetary value can be wagered, and a security module operable to perform at least one encryption function on information communicated via a network connection. The encryption functions include in various embodiments key management, authentication, or other encryption functions such as symmetric, asymmetric, hash, or message authentication code functions.

RELATED APPLICATIONS

This application claims the priority benefit of U.S. ProvisionalApplication Ser. No. 60/700,943 filed Jul. 20, 2005 and U.S. ProvisionalApplication Ser. No. 60/728,444 filed Oct. 20, 2005, the contents bothof which are incorporated herein by reference.

COPYRIGHT

A portion of the disclosure of this patent document contains material towhich the claim of copyright protection is made. The copyright owner hasno objection to the facsimile reproduction by any person of the patentdocument or the patent disclosure, as it appears in the U.S. Patent andTrademark Office file or records, but reserves all other rightswhatsoever. Copyright 2005, 2006 WMS Gaming, Inc.

FIELD OF THE INVENTION

The invention relates generally to computerized wagering game machines,and more specifically to a wagering game machine utilizing encryption,authentication, and key management.

BACKGROUND

Computerized wagering games have largely replaced traditional mechanicalwagering game machines such as slot machines, and are rapidly beingadopted to implement computerized versions of games that aretraditionally played live such as poker and blackjack. Thesecomputerized games provide many benefits to the game owner and to thegambler, including greater reliability than can be achieved with amechanical game or human dealer, more variety, sound, and animation inpresentation of a game, and a lower overall cost of production andmanagement.

The elements of computerized wagering game systems are in many ways thesame as the elements in the mechanical and table game counterparts inthat they must be fair, they must provide sufficient feedback to thegame player to make the game fun to play, and they must meet a varietyof gaming regulations to ensure that both the machine owner and gamerare honest and fairly treated in implementing the game. Further, theymust provide a gaming experience that is at least as attractive as theolder mechanical gaming machine experience to the gamer, to ensuresuccess in a competitive gaming market.

Computerized wagering games do not rely on the dealer or other gameplayers to facilitate game play and to provide an entertaining gameplaying environment, but rely upon the presentation of the game andenvironment generated by the wagering game machine itself. Incorporationof audio and video features into wagering games to present the wageringgame, to provide help, and to enhance the environment presented aretherefore important elements in the attractiveness and commercialsuccess of a computerized wagering game system. It is not uncommon foraudio voices to provide instruction and help, and to provide commentaryon the wagering game being played. Music and environmental effects arealso played through speakers in some wagering game systems to enhance orcomplement a theme of the wagering game. These sounds typicallyaccompany video presentation of the wagering game on a screen, whichitself often includes animation, video, and three-dimensional graphicsas part of presentation of the wagering game.

Modern wagering game system also typically employ a network connectionenabling each wagering game machine to communicate with othercomputerized systems on the network. For example, a progressive areaslot controller will coordinate the progressive slot jackpot andcoordinate selection of a winner by communicating with each wageringgame machine that is a part of the progressive jackpot pool. Computersare used for other purposes, such as for accounting, for tracking ratesof game play, and for receiving service requests or malfunctionnotification. The wagering game machine can be the recipient ofinformation, such as where configuration information like an audiovolume level is sent or specified via the network connection. Softwareupdates such as new multimedia files, new game code, operating systemchanges, and other such data can also be sent via the network connectionto a wagering game machine.

But, because significant amounts of money are being wagered on thewagering game machines, the security of network communications is animportant consideration. A cheat who is able to intercept or falsifymessages on the network could conceivably change the operation orconfiguration of wagering game machines, as well as interfere withaccounting for specific wagering game machines or progressive slotmachine controllers.

It is therefore desirable to ensure secure communication between awagering game machine and other computerized systems in a network.

SUMMARY

One example embodiment of the invention comprises a computerizedwagering game system including a gaming module comprising gaming codewhich is operable when executed on to conduct a wagering game on whichmonetary value can be wagered, and a security module operable to performat least one encryption function on information communicated via anetwork connection. The encryption functions include in variousembodiments key management, authentication, or other encryptionfunctions such as symmetric, asymmetric, hash, or message authenticationcode functions. Some further embodiments include encryption of networkpackets such as via the IPSec Internet security protocol.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a computerized wagering game machine, as may be used topractice some example embodiments of the invention.

FIG. 2 is a flowchart of asymmetric public key encryption algorithm keyexchange using an interlock protocol, consistent with some exampleembodiments of the invention.

FIG. 3 is a flowchart of a method of key exchange using digitalsignature encryption methods, consistent with some example embodimentsof the invention.

FIG. 4 is a flowchart of a method of key exchange and systemauthentication, consistent with some example embodiments of theinvention.

FIG. 5 is a flowchart of a method of using a message authentication codeto authenticate a server on a wagering game network, consistent withsome example embodiments of the invention.

FIG. 6 is an example X.509 certificate, consistent with some exampleembodiments of the invention.

FIG. 7 is a block diagram illustrating a wagering game network and acertificate management structure, consistent with some exampleembodiments of the invention.

FIG. 8 is a flowchart of a method of using certificates to ensure securecommunication between a back-end server and wagering game systems,consistent with some example embodiments of the invention.

FIG. 9 is a flowchart of a method of manually confirming trust in acertificate authority's certificate in a wagering game machine,consistent with some example embodiments of the invention.

DETAILED DESCRIPTION

In the following detailed description of example embodiments of theinvention, reference is made to specific examples by way of drawings andillustrations. These examples are described in sufficient detail toenable those skilled in the art to practice the invention, and serve toillustrate how the invention may be applied to various purposes orembodiments. Other embodiments of the invention exist and are within thescope of the invention, and logical, mechanical, electrical, and otherchanges may be made without departing from the subject or scope of thepresent invention. Features or limitations of various embodiments of theinvention described herein, however essential to the example embodimentsin which they are incorporated, do not limit the invention as a whole,and any reference to the invention, its elements, operation, andapplication do not limit the invention as a whole but serve only todefine these example embodiments. The following detailed descriptiondoes not, therefore, limit the scope of the invention, which is definedonly by the appended claims.

One example embodiment of the invention comprises a computerizedwagering game system including a gaming module comprising gaming codewhich is operable when executed on to conduct a wagering game on whichmonetary value can be wagered, and a security module operable to performat least one encryption function on information communicated via anetwork connection. The encryption functions include in variousembodiments key management, authentication, or other encryptionfunctions such as symmetric, asymmetric, hash, digital signature, ormessage authentication code functions. Some further embodiments includeencryption of network packets such as via the IPSec Internet securityprotocol

FIG. 1 illustrates a computerized wagering game machine, as may be usedto practice some embodiments of the present invention. The computerizedgaming system shown generally at 100 is a video wagering game system,which displays information for at least one wagering game upon whichmonetary value can be wagered on video display 101. Video display 101 isin various embodiments a CRT display, a plasma display, an LCD display,a surface conducting electron emitter display, or any other type ofdisplay suitable for displaying electronically provided displayinformation. Alternate embodiments of the invention will have other gameindicators, such as mechanical reels instead of the video graphics reelsshown at 102 that comprise a part of a video slot machine wagering game.

A game of chance is implemented using software within the wagering game,such as through instructions stored on a machine-readable medium such asa hard disk drive or nonvolatile memory. In some further exampleembodiments, some or all of the software stored in the wagering gamemachine is encrypted or is verified using a hash algorithm or encryptionalgorithm to ensure its authenticity and to verify that it has not beenaltered. For example, in one embodiment the wagering game software isloaded from nonvolatile memory in a compact flash card, and a hash valueis calculated or a digital signature is derived to confirm that the datastored on the compact flash card has not been altered. The game ofchance implemented via the loaded software takes various forms indifferent wagering game machines, including such well-known wageringgames as reel slots, video poker, blackjack, craps, roulette, or hold'em games. The wagering game is played and controlled with inputs suchas various buttons 103 or via a touchscreen overlay to video screen 101.In some alternate examples, other devices such as pull arm 104 used toinitiate reel spin in this reel slot machine example are employed toprovide other input interfaces to the game player.

Monetary value is typically wagered on the outcome of the games, such aswith tokens, coins, bills, or cards that hold monetary value. Thewagered value is conveyed to the machine through a changer 105 or asecure user identification module interface 106, and winnings arereturned via the returned value card or through the coin tray 107. Soundis also provided through speakers 108, typically including audioindicators of game play, such as reel spins, credit bang-ups, andenvironmental or other sound effects or music to provide entertainmentconsistent with a theme of the computerized wagering game. In somefurther embodiments, the wagering game machine is coupled to a network,and is operable to use its network connection to receive wagering gamedata, track players and monetary value associated with a player, and toperform other such functions.

The network connection is operable in some embodiments of the inventionto receive and transmit information that is desirably confidential, orthat would benefit from authentication of the message or the sender.Examples include a wagering game system sending accounting informationto a central accounting server, or a progressive slot machine controllertracking the amount wagered on wagering machines in the progressive areanetwork for calculation of the progressive jackpot. Various embodimentsof the invention use encryption techniques, such as messageauthentication, key management, hash functions, and other methods toensure the security or authenticity of information communicated over thewagering game network.

Protection of the wagering game data takes different forms in varyingembodiments of the invention, including but not limited to varioussymmetric algorithms, public key algorithms, and one-way hash functions.Various embodiments of the invention rely on algorithms such as thesebeing implemented in hardware or in software in the wagering gamesystems and in other systems such as servers or controllers, such aswithin a software driver executing on each system in the wagering gamenetwork.

Further embodiments encrypt network data sent between two wagering gamesystems using a protocol that operates on the network interface level,such as SSL or Secure Socket Layer, which is a secure protocol thatsupports a variety of encryption algorithms and functions, or IPSec,which includes encryption, authentication, and key management protocols.Every packet of information that is exchanged between two systems can beencrypted after a secure connection is established using a networksecurity protocol such as these, making them particularly well-suitedfor certain wagering game system network environments.

Encryption of data typically takes place with a symmetric or asymmetricalgorithm, designed to obscure the data such that a specific key isneeded to read or alter the data. A symmetric algorithm relies onagreement of a secret key before encryption, and the decryption key iseither the same as or can be derived from the encryption key. Secrecy ofthe key or keys is vital to ensuring secrecy of the data in suchsystems, and the key must be securely distributed to the receiversbefore decryption such as via a secure key exchange protocol. Commonsymmetric algorithms include DES, 3DES or triple-DES, AES, Blowfish,Twofish, IDEA, RD2, RC4, and RC5.

Public key algorithms, or asymmetric algorithms, are designed so thatthe decryption key is different than and not easily derivable from theencryption key. The term “public key” is used because the encryption keycan be made public without compromising the security of data encryptedwith the encryption key. Anyone can therefore use the public key toencrypt a message, but only a receiver with the corresponding decryptionkey can decrypt the encoded data. The encryption key is often called thepublic key, and the decryption key is often called the private key insuch systems. Such systems can also be used to digitally sign a documentwhere the signer uses the secret private key to encrypt the document orsome portion of it such as a one-way hash of the document, and thenpublishes the encrypted message. Anyone can use the signer's publishedor known public key to decrypt the signed message, confirming that itwas encrypted or signed by the owner of the public/private key pair.Common public key algorithms include RSA, Diffie-Hellman, and ElGamal.

One-way hash functions take an input string and derive a fixed lengthhash value. The hash value is typically of significantly shorter lengththan the input string message, and is often calculated by application ofsome type of lossy data compression algorithm. The functions aredesigned so that it is extremely difficult to produce an input stringthat produces a certain hash value, resulting in a function that isconsidered one-way. Data can therefore be checked for authenticity byverifying that the hash value resulting from a given one-way hashfunction is what is expected, making authentication of data relativelycertain. Hash functions can be combined with other methods of encryptionor addition of secret strings of text in the input string to ensure thatonly the intended parties can encrypt or verify data using the one-wayhash functions. Common examples of one-way hash function encryptioninclude MD2, MDC2, MD4, MD5, and SHA.

A variation on one-way hash functions is use of Message AuthenticationCodes, or MAC. A MAC comprises a one-way hash function that furtherincludes a secret key, such that knowledge of the key is necessary toencode or verify a given set of data. MACs are particularly useful wherethe hash value would otherwise be subject to unauthorized alteration orreplacement, such as when transmitted over a public network or a networkthat would be difficult to protect, such as a very large network linkinghundreds of computerized wagering game machines in a large gamingfacility. Examples of message authentication code algorithms includeHMAC algorithms such as HMAC-MD5, HMAC-SHA1, and other such hashfunction algorithms incorporating a key.

Encryption can be used in its various forms to obscure the content of amessage for transmission over a wagering game network, so that a thirdparty is not so easily able to monitor network traffic and read or altermessages sent over the network. The ability of various wagering gamesystems to communicate with one another securely relies in manyembodiments on the secure distribution or storage of keys, such asdistributing a symmetric key securely to both parties wishing to use thekey for secure communication, or distributing asymmetric keys such aspublic keys in a manner such that the identity of the public key ownerscan be firmly established. This is achieved in some embodiments byestablishing chain of trust from one trusted system to another, so thatonce a single system is declared to be authentic and trustworthy, it can“vouch” for other systems such as by authenticating their public keys,user-unique identifiers, asymmetric keys, or other such data.

Key management is therefore also an important aspect of implementingencryption technology in many applications. Periodically changing orrotating encryption keys over time reduces the amount of time a cheathas to try to derive or calculate a secret key while it is still beingactively used, and reduces the amount of data available to the cheat ifa key is compromised. Some systems therefore not only rotate keys, butnegotiate or exchange a new encryption key each time communication isestablished with another party, using protocols commonly known as keyexchange protocols.

In one example, a shared secret symmetric key is present in each of twosystems connected to the wagering game network. The machine requestingsecure communication requests a session key from a trusted third party,such as a key server on a trusted server. The key server generates asession key and encrypts two copies of it using the secret symmetrickeys of the two systems wishing to communicate securely. The key serversends the encrypted keys to the first system, which decrypts the copyencrypted with its asymmetric key and sends the other copy on to theother system. The other system receives and decrypts its key, and thetwo systems use the session key to communicate securely. This system isable to securely deliver a session key to each of the two partiesdesiring a secure communications session, but requires a trusted thirdparty that knows the secret symmetric keys of the communicating parties.

In another example of key exchange, a public key or asymmetric keyalgorithm is used to exchange keys between two wagering game networksystems desiring a secure communications channel. A first system A cansimply get the public key of another system B from a key managementauthority such as a trusted public key server, and encrypt a randomlygenerated session key using that public key. System A then sends theencrypted session key to B, which decrypts the session key using itsprivate key, and uses the decrypted session key to communicate withsystem A. But, such a system is vulnerable to someone interceptingmessages such as public keys and encrypted messages on the network andsubstituting their own messages, so that the “man in the middle” is ableto intercept, read, and alter any messages sent between the two systems.

FIG. 2 shows an example of application of an asymmetric public keyencryption algorithm to key exchange using an interlock protocol,consistent with an example embodiment of the invention. The interlockprotocol greatly reduces the ability of a “man in the middle” tointercept and replace messages during key exchange by splitting up theexchange into interlocking steps.

The two communicating systems A and B exchange public keys at 201, suchas by publishing them in a trusted database or key management authorityor by simply sending the keys to one another via a message. System Aencrypts a message (the content of the message is relativelyunimportant, but in some embodiments is a session key or part of asession key) using system B's public key and sends half of the encryptedmessage to system B at 202. System B similarly encrypts its messageusing system A's public key at 203, and sends half of its encryptedmessage to system A. At 204, system A sends the other half of itsencrypted message to system B, and at 205, system B combines the twomessage halves and decrypts the message using its private key. System Bthen sends the other half of its encrypted message to system A, whichreceives the second half of the message at 206, and combines the twohalves of the message and decrypts it using its private key.

Because half of the message is useless without the other half, and bothsystems have sent half of the message before either system is able todecrypt the message received from the other system, a “man in themiddle” will have much more difficulty in substituting its keys andmessages for those of either system A or B. In some further examples,the first half of the message contains the even numbered bits while thesecond half contains the odd numbered bits, so that no block of dataremains intact and decryptable without both halves of the message beingpresent. In another example, decryption is performed using a protocolwith an initialization vector, which is only provided with the secondhalf of the message. The first half of the message can also containinformation such as a one-way hash of the encrypted message, while thesecond half of the message is the encrypted message itself.

Key exchange can also be performed using digital signature encryptionmethods, such as is shown in the example of FIG. 3. System A signs amessage at 301, but then appends an identifier to the message such as auser-unique identifier (UUID), media access control address (MACaddress), processor serial number, or other such identifier. Thecombined message is then again digitally signed by encrypting it withsystem A's private key. At 302, system A sends the key to a trustedthird party system S, which confirms A's signature and identifier, thentimestamp's A's message and signs it before sending it to systems A andB at 303.

When system B receives the signed message, it verifies system S'ssignature, the identifier, and A's signature, and can further make noteof the time stamp to see the age of the message. System A receives acopy of the message as well, as notification that a message was sent sothat should a cheat be able to compromise system A's keys and imitatesystem A, system A has notice of the false message.

More simple methods of using digital signatures are sufficient for someenvironments, such as where a timestamp is deemed unnecessary. Forexample, if system A were to generate a session key, encrypt a messageusing the session key, and encrypt the session key using B's public key,only B can decrypt the session key and use it to read the message. Thisassumes that system A has access to a secure or trusted copy of B'spublic key, such as from a trusted key server or as provided by atechnician upon installation of the system into the wagering gamenetwork. For added security system A can sign the message, the encryptedsession key, or both using its public key so that system B can confirmA's identity upon receiving the encrypted message and session key byusing system A's public key to decrypt the signed portion and confirmA's identity.

FIG. 4 illustrates a key exchange algorithm using Diffie-Hellman, inwhich the key itself is never actually exchanged but information derivedfrom the key is exchanged to negotiate a secure connection. The methodshown in FIG. 4 shows both a key exchange and authentication stages inestablishing a secure connection between two devices in a wagering gamenetwork.

The initiator and the respondent initially communicate at 401, andnegotiate the algorithm and parameters to be used based on thealgorithms and parameters supported by the software installed on eachsystem. The initiator creates a local secret “a”, and generates at 402 apublic value x(a)=A that is a function of the locally generated secret‘“a”. The secret “a” can be a random number, a user-unique identifier, asecret key, or any other such secret, and in some embodiments includestime-based information to prevent a cheat from replaying the keyexchange messages as part of a replay attack. The responder similarlycreates a local secret “b” at 403, and generates a publicly shareablevalue x(b)=B such that “B” is a function of the local secret “b”.

The initiator then encrypts the message “A” with a preshared encryptionkey and sends it to the responder at 404, and the responder encrypts thepublicly shareable value “B” with the preshared encryption key and sendsit to the initiator. At 406, the initiator decrypts “B”, and generatesone or more session keys based on the values “a” and “B” such that thekeys are f(a,B). Similarly, the responder decrypts “A” at 407, andgenerates the same one or more session keys based on the values “A” and“b”, such that the keys are f(A,b).

Because the keys cannot be recovered as a function of A and B, or asf(A,B), someone intercepting and decrypting the public values A and Bwill be unable to generate the same session keys generated by theinitiator and respondent at 406 and 407. The result is a secure methodof key exchange that doesn't require the session key itself to be sentfrom one system to the other, making it more difficult for a third partyeven with knowledge of the preshared encryption key to intercept orderive the session keys.

Some embodiments further include authentication, such as by using amessage authentication code, an encryption key, and shared data known toboth the initiator and respondent. At 408 and 409, both the initiatorand respondent create message authentication codes such as keyed-hashmessage authentication codes (HMACs) of shared data using a session keygenerated at 406 or 407. The shared data comprises in some embodimentsthe same list of available encryption algorithms, that was used as aparameter in the key exchange negotiation process at 401, but containsother information in alternate embodiments. The data is in someembodiments data known only to the initiator and responder, such as thepreviously exchanged list of available encryption algorithms or a sharedsecret. The shared data need not be the same data for both the initiatorand responder, but can be data the responder has shared with theinitiator at 408 and data the initiator has shared with the responder at409.

The shared data is encrypted with a key shared by both the initiator andresponder at 410 and 411. The HMAC produced by the initiator isencrypted and sent to the responder at 410, while the HMAC produced bythe responder is encrypted and sent to the initiator at 411. Encryptionof the HMAC is performed in some embodiments with a session key, such asa public key of an asymmetric key pair generated as a session key pair,but is another type of encryption key in alternate embodiments.

The initiator receives the encrypted HMAC from the responder anddecrypts it at 412, and compares the HMAC to a locally generated HMACbased on the same session key, shared data, and HMAC algorithm as theresponder used to generate the received HMAC. If the received HMAC andthe locally generated HMAC are the same, the responder is authenticated.Similarly, the responder decrypts the HMAC received fro the initiator at413 and compares it to a locally calculated HMAC based on the same dataand algorithms, and compares it to authenticate the initiator.

Once authentication is complete, the two parties can communicatesecurely using one or more session keys at 414, trusting that the otherparty is authentic and that communication with the other party isreasonably secure.

Key exchange and authentication can therefore range from simple use of ashared secret such an asymmetric key to relatively complex algorithmswhere trusted third parties authenticate, time stamp, or perform otherfunctions to further enhance communication security. Examples of othersuch key exchange and authentication algorithms include El Gamal,Wide-Mouth Frog, Yahalom, Needhan-Schroeder, Otway-Rees, Kerberos,Neuman-Stubblebine, Dass, Denning-Sacco, Woo-Lam, and many other suchprotocols using public key, symmetric key, and other encryption methods.

Sometimes, verifying the authenticity of a message is significantly moreimportant than keeping the message secret, such as when communicatingaccounting information from a wagering game to a server such as whenreporting credits played to a progressive area server or authenticatinga jackpot amount or jackpot win message from a progressive area server,or in some methods of authenticating the identity of another device inthe wagering game network. Hash functions can be used to confirm that aparticular message or document has not been altered since its one-wayhash function was generated, or can be combined with a key so that onlysomeone with knowledge of the key can confirm the hash value of aparticular message. Such a hash function combined with a key is called amessage authentication code, or MAC, and can be used to authenticate thecontent of messages between users and to confirm that the sender of amessage had possession of the key used to generate the messageauthentication code.

Consider for example a network of wagering game systems having a secretshared symmetric key or each having a symmetric key shared with aserver. The key can be distributed by a wagering game technician, or canbe established as a session key using key exchange and distributionmethods as discussed previously. A wagering game can sign each messagewith a message authentication code, and the recipient can compute thesame message authentication code with a one-way hash function and thesecret key. By comparing the received message authentication code withthe one calculated locally, the message receiver can be relativelycertain the message was signed by another system having the secret keyused in the message authentication code.

FIG. 5 is a flowchart of a more detailed method of a wagering gamesystem using a message authentication code to authenticate a server on awagering game network. A wagering game system technician first requestsat 501 a hardware-based key to use with a hash function in generating amessage authentication code. The server responds by generating the keyat 502 if it hasn't yet been generated, or retrieves the key if it hasalready been generated and stored such as by retrieving the key fromsecure storage in a Trusted Platform Module. The key is in someembodiments based on a hardware characteristic, such as derived from auser-unique identifier (UUID), a processor serial number, a media accesscontrol (MAC) address, or other such hardware characteristics likely tobe unique.

The server sends the key to the technician at 503, such as bytransferring it to a secure memory storage device such as a smartcard orUSB device supporting data storage. In a further embodiment, a checksumis appended to the key and is transferred to the technician along withthe key to ensure accurate transcription of the key. The techniciantransfers the key to the client system at 504, along with the checksumif present, and the client system receives the key and checksum at 504and confirms that the checksum is consistent with the received key.

Once the server and client system have the same securely distributedkey, either system can challenge the identity of the other system. At505, the client system issues a challenge to the server, such as bygenerating a random number and sending the random number to the serveras part of the challenge process. The server receives the random numberand performs a predetermined operation at 506, such as adding one to thenumber or performing some other mathematical operation, and generates amessage authentication code for the modified random number based on aone-way hash function and the shared hash key at 507. The server thensends the modified random number back to the challenging client systemat 509, along with the generated message authentication code.

Meanwhile, the client system has also performed the predeterminedoperation on the random number sent as a challenge, and has used thehash key and the one-way hash function to generate its own messageauthentication code for the challenge value at 508. The client comparesthe message authentication code and the modified random value itgenerated to those received from the server at 510, and can concludethat the server is authentic and has knowledge of the secret hash key ifthe message authentication codes and modified random numbers match.

This solution to authentication recognizes the difficulty ofdistributing an initial identifier or key, and serves to illustrate howa chain of trust can be used to authenticate the identity of varioussystems. Were the hash key distributed in software rather than based onthe hardware of the server, a potential cheat could simply obtain a copyof the software and pose as the server with no knowledge of the serveror physical access to the server. Here, the technician securelydistributes a shared secret key, such as one derived from hardwarecharacteristics or randomly generated within the server system. Use of ashared secret enables authentication by confirming some aspect of theshared secret, such as confirming a keyed hash value using a secret keyor decrypting a message using a secret key.

In some examples, several wagering game systems in a wagering gamenetwork can share the same secret with the server, meaning that thewagering game systems can use an authentication process such as that ofFIG. 4 or 5 to authenticate its identity and establish securecommunications with any other machine in the network that has the sharedsecret. In other examples, each system shares a different secret withthe server, and the server coordinates authentication of one wageringgame system to the other for communication such as was described earlierin discussing the key exchange protocols.

Implementation of encryption protocols into a wagering game system isperformed in some embodiments by adoption of standards such as theInternet Protocol Security (IPSec) protocol set or another suchstandard. IPSec comprises a set of protocols including secure packettransmission protocols and key exchange protocols, and can therefore beused for a variety of encryption functions such as secure communication,authentication, and key management. IPSec works on the networkconnection of a computer system, so it has the ability to encrypt orprotect packets sent over the network whatever their content. IPSec alsoincludes the key exchange protocol known as Internet Key Exchange (IKE),which is used to establish a secure association for encrypted packetexchange between two or more systems. IKE uses a Diffie-Hellman basedkey exchange to set up a shared session secret, from which cryptographickeys are derived. Either preshared secrets or public key methods asdescribed earlier are used to mutually authenticate communicatingparties, such that the identity of a party can be confirmed beforeestablishing a session key.

More simple protocols such as Secure Socket Layer (SSL) can also be usedto provide system authentication and encryption of network data. SSLincludes a negotiation element in which the communicating partiesnegotiate which encryption standards will be used. Supported optionsinclude public key algorithms such as RSA and Diffie-Hellman, symmetrickey algorithms such as RC4, IDEA, DES, AES, and has functions such asMD5 and SHA. It further supports message authentication codes, and iscommonly used to support secure communication for electronic commerceconducted over the Internet. SSH is typically implemented in the sessionor transport layers of a network stack, and so is capable of providingencryption services to a network connection independent of the specificapplication requesting network communication.

Key management includes certificate management in a further embodiment,such as where the security module is operable to authenticate acertificate to establish trust in an encryption key embedded therein.Authentication of the certificate is performed via a certificateauthority's certificate, which is trusted through manual confirmation ofthe authenticity of the certificate authority's certificate such asmanual confirmation of a known hash value of the certificate authority'scertificate. The invention in one such example uses encryption methodsto ensure secure communication between network devices by establishingtrust in encryption keys embedded in certificates. A security module inthe wagering game system or server is operable to authenticate acertificate to establish trust in an encryption key embedded therein,such that the encryption key can be trusted as belonging to theidentified owner. Authentication of the certificate is performed via acertificate authority's certificate, which is trusted in someembodiments through manual confirmation of the authenticity of thecertificate authority's certificate such as manual confirmation of aknown hash value of the certificate authority's certificate.

Use of encryption once trust or authenticity are established in awagering game network takes different forms in varying embodiments ofthe invention, including but not limited to use of various symmetricalgorithms, public key algorithms, and one-way hash functions. Variousembodiments of the invention rely on algorithms such as these beingimplemented in hardware or in software in the wagering game systems andin other systems such as servers or controllers, such as within asoftware driver executing on each system in the wagering game network.Further embodiments encrypt network data sent between two wagering gamesystems using a protocol that operates on the network interface level,such as SSL or Secure Socket Layer, which is a secure protocol thatsupports a variety of encryption algorithms and functions, or IPSec,which includes encryption, authentication, and key management protocols.Every packet of information that is exchanged between two systems can beencrypted after a secure connection is established using a networksecurity protocol such as these, making them particularly well-suitedfor certain wagering game system network environments.

As previously discussed, encryption can be used in its various forms toobscure the content of a message for transmission over a wagering gamenetwork, so that a third party is not so easily able to monitor networktraffic and read or alter messages sent over the network. The ability ofvarious wagering game systems to communicate with one another securelyrelies in many embodiments on the secure distribution or storage ofkeys, such as distributing asymmetric keys such as public keys in amanner such that the identity of the public key owners can be firmlyestablished. This is achieved in some embodiments by establishing chainof trust from one trusted system to another, so that once a singlesystem is declared to be authentic and trustworthy, it can “vouch” forother systems such as by authenticating their public keys, user-uniqueidentifiers, asymmetric keys, or other such data.

Such methods of key management are often handled via a trusted thirdparty known as a Certificate Authority, which is a service provider thatsigns certificates carrying public keys and identification informationas a means of authenticating the data contained in the certificate toother parties. The certificate authority is typically a party well-knownand trusted to all involved, and in some environments such as Internetweb pages is preconfigured as a trusted authority in web browsers beforedistribution.

FIG. 6 illustrates the content of a typical X.509 standard compliantcertificate, including identification information and a digitalsignature authenticating the information contained therein. Thecertificate contains a version identifier indicating which set ofcertificate standards were used in assembling the certificate at 601,and fields identifying the algorithm used to digitally sign thecertificate at 602. the certificate authority, or trusted third partysigning the certificate is identified at 603, including a variety offields useful in identifying or contacting the certificate authority.

The certificate's period of validity is specified at 604, and istypically based on cost, the level of security desired, and otherfactors. The subject of the certificate is identified at 605,identifying the entity whose public key is being conveyed via thecertificate and other information such as the internet address andcontact information for the entity. The subject's public key andinformation regarding the type of encryption algorithm used to createthe public key are shown at 606, and an encrypted digital signatureincorporating a hash algorithm from the certificate authority vouchingfor the authenticity of the other data contained in the certificate isshown at 607.

In use, the subject is able to provide the certificate to other parties,who can use their previous knowledge and trust of the certificateauthority to accept the authenticity of the certificate's contents,including the certificate owner and the owner's public key. Thecertificate authority's own certificate is thereby used as a root oftrust, through which the certificate authority can vouch for othercertificates and subjects through digitally signing the subject'scertificates.

For example, consider a wagering game manufacturer that wishes to ensuresecure communications between gaming devices and a server. Themanufacturer generates a public key/private key encryption pair, andapplies to a certificate authority to have its public key signed. Thecertificate authority creates a certificate like that of FIG. 6containing the wagering game server's public key and identificationinformation, and provides the certificate to the wagering game systemmanufacturer. In another example, the wagering game manufacturer, agaming regulation board, or another such entity acts as its owncertificate authority, and issues signed certificates to wagering gameservers or other systems. The signed certificate generated for thewagering game server is then distributed to gaming devices such as thecomputerized reel slot machine of FIG. 1, which can authenticate thecertificate based on the wagering game machine's trust of thecertificate authority. Once the certificate is deemed trusted based onauthentication of the digital signature, the wagering game system canuse the public key embedded in the certificate to communicate securelywith the wagering game server.

The certificate of FIG. 6 contains an RSA public key as shown at 606,owned by the subject identified at 605. The RSA public key can be usedto encrypt a message sent to the subject, or can be used to confirm anRSA digital signature of the subject to ensure that communication to andfrom the subject is authentic and secure. The certificate is signed byuse of an MD5 hash value, encrypted with the certificate authority'sprivate RSA encryption key. The authenticity of the certificate cantherefore be confirmed by decrypting the hash value using thecertificate authority's known public key, such as is typically builtinto web browsers, is otherwise distributed so widely it is inherentlytrusted, or as is otherwise securely delivered in a trustworthy manner.Once the hash value is decrypted, it can be compared to a computed hashof the certificate, such that if the hash values match the certificateis known to be unaltered since being signed by the certificateauthority.

A more detailed example of incorporation of certificates in a wageringgame system is shown in FIG. 7. Because the wagering game systemmanufacturer desires in this example only to authenticate one componentof its system to another, it acts as its own certificate authority. Inother examples, publicly known and trusted certificate authorities suchas Verisign or Thwate are relied upon to sign a certificate such as themanufacturer's certificate, extending the root of trust beyond themanufacturer. In still another example, a particular casino or gamingauthority such as the State of Nevada's Gaming Board will sign amanufacturer's certificate, acting as a link in the chain of trust.

The certificate authority 701 first makes known its public key, such asby publishing it to software designed to facilitate secure communicationbetween wagering game system components or by publishing it such that itis widely or freely available. In this example, the back-end serversystem 701 has a certificate signed by the certificate authority, andthe wagering game machines 702 also have a common certificate signed bythe certificate authority and shared by every wagering game system onthe network.

The wagering game devices 703 are desirably able to authenticatecommunication with the back-end server 702, so that information such asaccounting information, configuration or game changes, progressive gameprogress, and other such data communicated via the network is known tobe authentic. One example of a process using certificates forauthentication in the wagering game system of FIG. 3 is shown in theflowchart of FIG. 4.

The backend server 702 generates or receives a public key/private keypair of keys, and has the certificate authority 701 create acertificate, vouching for the authenticity of the public key. Thewagering game devices 703 similarly have the certificate authorityprovide a certificate including a public key, and store thecorresponding private key. In this example, the secrecy of the back-endserver's private key is of particular concern, as compromising the keywould enable a cheat to act as though it were the back-end server and toexercise some degree of control over the wagering games 703.

In some embodiments, the private key is kept securely in the back-endserver via a component known as a Trusted Platform Module, that preventsa cheat from examining hardware settings or software code to steal theprivate key. The back-end server key pair is generated in the serverduring the installation process in some embodiments, greatly reducingthe risk that a cheat could obtain the private key used by interceptingthe server before installation. When the keys are generated during theinstallation process, the keys and related certificates are stored innonvolatile memory on systems not having a Trusted Platform Module, butbecause the keys and certificates are generated locally they will oftennot include a certificate generated by a pre-trusted certificateauthority for authentication of the distributed public key.

To solve the problem of authenticating the server's public key to thegaming devices, the backend server authenticates its own gaming devicecommunication keys by creating a certificate, and creates and signs acertificate for the wagering game devices 703 as well. FIG. 8 is aflowchart of a method of using certificates to ensure securecommunication between a back-end server and wagering game systems,consistent with some example embodiments of the invention. The backendserver therefore creates three key pairs and signs the public keys oftwo pairs in this example—a certificate authority key pair used to signother key pairs at 801, a key pair and signed certificate for theback-end server to communicate over the network with gaming devices at802, and a key pair and signed certificate for the gaming devices toshare in communicating with the back-end server at 803.

The backend server publishes the certificate authority's certificate,the wagering game machine's certificate, and the wagering game device'spublic key at 804. This information is published to a domain name serverin some embodiments, or to another server such as a key server. Thewagering game device's private key is not published in alternateembodiments, but is conveyed to the wagering game machines via a networkconnection or through technician intervention such as by use of a smartcard, USB flash drive, or other mechanism.

The wagering game device retrieves the published certificates and keysat 805, including its own private key in this example embodiment. Thisis permitted, as the authenticity of the wagering game machine itself isnot of concern in this example but the authenticity of the back-endserver is important. In an alternate embodiment, the wagering gamedevice's private key is obtained in the wagering game device throughother means. The wagering game device then stores its private key,stores its certificate for sharing with other devices, and stores thecertificate authority's certificate for authenticating the certificateauthority's signature. In some embodiments, the wagering game systemchecks its own certificate using the certificate authority's public keyto ensure that the certificates and the private key received areconsistent.

In an alternate example, a trusted platform module is available on theserver and in the wagering game devices, and can be used for keygeneration and storage. In one such example, the server's trustedplatform module is used to generate the certificate authority and serverkeys, but is not used to generate the wagering game device's key pairsince the private key can't be easily extracted from the trustedplatform module for transfer to the wagering game devices. In analternate embodiment, the server's trusted platform module does generatethe wagering game device keys, which are securely transferred to thewagering game devices such as by use of a secure portable memory such asa smart card or flash drive device.

The gaming device generates its own key pair in other embodiments, andthe public key created in the gaming device is securely conveyed to theserver so that it can sign the public key and create a trusted X.509certificate, which can then be made publicly available to all systems onthe network to facilitate future secure and authenticated communication.

Returning to the example of FIG. 8, in which the keys and certificatesare generated in the server, the technician intervenes in the process at806 to manually confirm the authenticity of the certificate authority'scertificate as received in the wagering game machine. This is achievedin this embodiment by generation of a hash value, such as by using anMD5 or other hash algorithm, of the certificate authority's certificateat the backend server, and manually comparing the hash value observed atthe server to a hash value calculated in each wagering game machine.Once the hash values are confirmed to be the same, the certificateauthority's certificate can be accepted as authentic, such as by thetechnician following an on-screen prompt to confirm the calculated hashvalue. This is achieved in another example embodiment by the technicianconveying the certificate authority's certificate from the backendserver to each wagering game machine on installation, or by using someother means of securely or reliably conveying the certificateauthority's certificate to each of the wagering game machines. In yet afurther example, the technician views the actual certificate, such asvia a printed copy or portable electronic device, and confirms that itmatches the certificate received in the wagering game device.

The gaming device is then able to locate and initiate communication withthe backend server at 807, including exchange of certificates such asvia the standard Diffie-Hellman Internet Key Exchange protocol. Theauthenticity of the exchanged certificates can be confirmed by checkingthem with the certificate authority's public certificate, which is nowtrusted by both parties.

Establishment of a secure communications channel at this point variesfrom embodiment to embodiment, but includes such features as validatingexchanged certificates using the certificate authority's certificate,exchanging signed messages and confirming the signatures at thereceiving end using the exchanged certificates, and negotiating a securechannel such as by using an IPSec security association protocol.Establishment of session keys, or unique encryption keys for aparticular communications session, ensures the authenticity and secrecyof the information being exchanged, and is typically a part of a securechannel negotiation protocol such as IPSec.

The security of the connection between the wagering game devices and thebackend server is therefore authenticated from the viewpoint of thewagering game devices. In this example, the authenticity of the wageringgame devices has not been authenticated to the server due to the publicavailability of the wagering game device's private key, but theauthenticity of the gaming devices is not an issue in such examples. Inother examples, such as where a backend server records gaming progressof a pool of progressive slot machines, the wagering game devices couldbe impersonated to the advantage of a game player, and so the wageringgame machine's private keys are conveyed securely such as via atechnician.

The technician's role in the example of FIG. 8 is an important elementin establishing trust in the certificate authority's certificate, and isshown in greater detail in FIG. 9. Once the backend server has createdor received a certificate authority key pair and has generated orreceived a certificate authority certificate, a hash value of thecertificate is calculated using a one-way hash function at 901. Thebackend server then displays or conveys the result of the hash functionto the wagering game technician at 902, such as by displaying ahexadecimal alphanumeric string of characters on the screen. Thetechnician is then able to make note of the hash value, and use it forcomparison purposes later to ensure that a certificate is the same asthe certificate authority certificate stored in the backend server.

The wagering game system receives the certificate authority'scertificate at 903, and applies the same hash function as used in thebackend server at 901 to the received certificate. Because the hashfunction is the same, and because it is extremely difficult to forge acertificate that will generate a given hash result when an appropriateone-way hash function is used, identical hash values virtually guaranteethat the certificates are the same. The technician therefore ispresented the hash value calculated in the wagering game machine at 904,such as by displaying the computed hash value on the wagering gamesystem's display, and confirms that the hash value generated in thewagering game machine matches the hash value observed at the backendserver at 905.

Confirmation comprises in one embodiment use of a service orconfiguration screen on the wagering game system, which prompts thetechnician to compare the hash value generated in the wagering gamemachine to the hash value computed and presented from the backendserver. Once the technician has confirmed that the hash values match,the certificate authority's certificate is accepted in the wagering gamemachine as authentic at 906, and is stored such as in nonvolatilememory, a Trusted Platform Module, or is otherwise stored for later use.

This example shows how a root of trust, such as a certificateauthority's certificate, can be used in a wagering game system networkto provide the wagering game systems and servers on the network theability to securely communicate. The root of trust in the example givenmust be trusted in all devices wishing to securely communicate, and sois confirmed as being authentic in the wagering game systems using amanual technician intervention as explained in FIG. 9. The root of trustis here used to facilitate operation of a key exchange protocol byenabling use of signed certificates to securely exchange data betweensystems, which in one further example is the Internet Key Exchangeprotocol, or IKE. In a still further embodiment, session keys used toencrypt and decrypt data exchanged in a given communication session areexchanged using the key exchange protocol, which facilitates operationof a secure channel such as an IPSec secure communications channel. Avariety of further examples of key exchange, certificate management, andsession encryption, such as those previously discussed, can be appliedto or combined with elements of the method of FIG. 9 in variousalternate embodiments.

In one such example, Internet Protocol Security (IPSec) protocol set oranother such standard. IPSec comprises a set of protocols includingsecure packet transmission protocols and key exchange protocols, and cantherefore be used for a variety of encryption functions such as securecommunication, authentication, and key management. IPSec works on thenetwork layer of a computer system, so it has the ability to encrypt orprotect packets sent over the network whatever their content. IPSec alsoincludes the key exchange protocol known as Internet Key Exchange (IKE),which is used to establish a secure association for encrypted packetexchange between two or more systems. IKE uses a Diffie-Hellman basedkey exchange to set up a shared session secret, from which cryptographickeys are derived. The authenticated certificates or other methods suchas other preshared secrets or public key methods as described earlierare used to mutually authenticate communicating parties, such that theidentity of a party can be confirmed before establishing a session key.

Other protocols such as Secure Socket Layer (SSL) can also be used toprovide system authentication and encryption of network data inalternate embodiments. SSL includes a negotiation element in which thecommunicating parties negotiate which encryption standards will be used.Supported options include public key algorithms such as RSA andDiffie-Hellman, symmetric key algorithms such as RC4, IDEA, DES, AES,and has functions such as MD5 and SHA. It further supports messageauthentication codes, and is commonly used to support securecommunication for electronic commerce conducted over the Internet. SSHis typically implemented in the session or transport layers of a networkstack, and so is capable of providing encryption services to a networkconnection independent of the specific application requesting networkcommunication.

In a further example, at least some wagering game machines in a wageringgame network have one or more certificates from one or moreadministrative organizations pre-loaded in the system. Theadministrative organization's certificate is in some such examplesconsidered a root certificate, and is inherently trusted and can be usedto establish trust in other certificates or messages. The administrativeorganization in such cases will likely be an organization charged withsome role in managing the wagering game systems, such as the wageringgame system manufacturer, a casino or other wagering game establishmentowner or operator, or a regulatory authority such as the Nevada stategaming board.

The certificates can be pre-loaded in some embodiments by storing themin a trusted platform module during manufacture or initialconfiguration, or can be stored through other means such as bypreprogramming a read-only memory in the wagering game systems. Thesetrusted root certificate examples enable the wagering game machines torecognize and confirm the authenticity of messages signed by orencrypted by the root certificate owner, and enable recognition andtrust of other certificates signed by the root certificate owner. In amore sophisticated example, a preloaded root certificate from thewagering game manufacturer is used to establish trust in a casino ownercertificate signed by the game manufacturer, and the casino'scertificate is used or a limited period of time to sign certificatesassigned to a variety of servers and wagering game machines in thecasino. Each system can trust the other, because the casino owner'ssignature present in each machine's certificate can be authenticatedback to the wagering game manufacturer's certificate, which isinherently trusted in each machine. Similarly, secure communicationschannels can be negotiated, new software can be downloaded, and othernetwork communications can be secured or authenticated using the chainof trust established back to the administrative organization'scertificate serving as a preconfigured root of trust.

These examples illustrate how key management, data encryption,authentication, certificate management, and other encryption methods canbe used to provide greater security in a wagering game network. Thesecurity of communication and authentication of communicating partiesreduces the risk that a cheat will be able to intercept, alter, orchange information communicated between wagering game systems in awagering game network, thereby reducing the risk that an intruder willbe able to interfere with the normal operation of the wagering gamenetwork or those devices relying on the network to operate properly.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiments shown. This application isintended to cover any adaptations or variations of the exampleembodiments of the invention described herein. It is intended that thisinvention be limited only by the claims, and the full scope ofequivalents thereof.

1. A computerized wagering game apparatus, comprising: a gaming modulecomprising gaming code operable to present a wagering game on whichmonetary value can be wagered; a network connection communicativelycoupled to the gaming module; and a security module operable tosequentially encrypt and transmit portions of an integral message viathe network connection using an exchanged key and an interlock protocol.2. The computerized wagering game apparatus of claim 1, wherein theportions transmitted via the network connection comprise network datapackets encrypted via IPSec.
 3. The computerized wagering game apparatusof claim 1, wherein the exchanged key comprises a public key.
 4. Thecomputerized wagering game apparatus of claim 1, wherein the securitymodule is operable to authenticate at least one of a received message oran identity of another computerized wagering game apparatus.
 5. Acomputerized wagering game system, comprising: a client machinecomprising gaming code operable to present a wagering game on whichmonetary value can be wagered, a network connection communicativelycoupled to the gaming module, and a client security module operable tosequentially encrypt and transmit portions of an integral client messagevia the network connection using one of a pair of exchanged keys and aninterlock protocol; and a server machine comprising a server securitymodule operable to sequentially receive the portions of the integralclient message, and to encrypt and transmit portions of an integralserver message via the network connection using another one of theexchanged keys and the interlock protocol.
 6. The computerized wageringgame system of claim 5, wherein the portions of the server messagetransmitted via the network connection comprise network data packets. 7.The computerized wagering game system of claim 5, wherein the serversecurity module is operable to combine the portions of the integralclient message into a single encrypted message that can be decryptedwith a private key to provide the integral client message.
 8. Thecomputerized wagering game system of claim 5, wherein one of theportions of the integral client message comprises at least part of asession key.
 9. The computerized wagering game system of claim 5,comprising: a trusted database to receive the pair of exchanged keys.10. A method, comprising: presenting a wagering game on which monetaryvalue can be wagered; and sequentially encrypting and transmittingportions of an integral message associated with the wagering game via anetwork connection using one of a pair of exchanged keys and aninterlock protocol.
 11. The method of claim 10, comprising: publishingthe pair of exchanged keys to at least one of a trusted database and akey management authority.
 12. The method of claim 10, comprising:exchanging the pair of exchanged keys via messaging between twonetworked systems.
 13. The method of claim 10, comprising: executing theinterlock protocol as an exchange of at least two encrypted messageportions.
 14. (canceled)
 15. The method of claim 10, wherein one of theportions comprises: part of a session key.
 16. The method of claim 10,comprising: combining the portions of the integral message into a singleencrypted message.
 17. The method of claim 10, comprising: decrypting asingle encrypted message to provide the integral message using a privatekey.
 18. The method of claim 10, wherein one of the portions compriseseven numbered bits of a block of data, and wherein another one of theportions comprises odd numbered bits of the block of data.
 19. Themethod of claim 10, comprising: decrypting a single encrypted message toprovide the integral message using an initialization vector included inother than a first one of the portions.
 20. A machine-readable mediumwith instructions stored thereon, wherein the instructions, whenexecuted, are operable to cause a computerized wagering game apparatusto: present a wagering game on which monetary value can be wagered; andsequentially encrypt and transmit portions of a first integral messageassociated with the wagering game via a network connection using one ofa pair of exchanged keys and an interlock protocol.
 21. Themachine-readable medium of claim 20, wherein the instructions, whenexecuted, are operable to cause a computerized wagering game apparatusto: sequentially receive and combine encrypted portions of a secondintegral message associated with the wagering game via a networkconnection to provide a single encrypted message. 22.-25. (canceled) 26.A computerized wagering game apparatus, comprising: a gaming modulecomprising gaming code operable to present a wagering game on whichmonetary value can be wagered; a network connection communicativelycoupled to the gaming module; and a security module operable to transmitchallenge data comprising a random number via the network connection,and to generate a message authentication code resulting from encryptinga result of performing a predetermined operation on the random number.27.-50. (canceled)